install: key the extraction cache slot by the registry URL, not only its hostname - #41636

Reproduction (two stub registries on one host, different port and path):

W=$(mktemp -d); cd $W; export HOME=$W/home BUN_INSTALL_CACHE_DIR=$W/cache; mkdir -p $HOME
# reg.js: serves /<prefix>/foo and /<prefix>/foo/-/foo-1.0.0.tgz, index.js exports the variant name
node reg.js 4873 /npm-public PUBLIC & node reg.js 4874 /npm-private PRIVATE &
for p in A B; do mkdir $p; echo '{"name":"'$p'","dependencies":{"foo":"1.0.0"}}' > $p/package.json; done
printf '[install]\nregistry = "http://127.0.0.1:4873/npm-public/"\n'  > A/bunfig.toml
printf '[install]\nregistry = "http://127.0.0.1:4874/npm-private/"\n' > B/bunfig.toml
(cd A && bun install && bun -p 'require("foo")')   # PUBLIC
(cd B && bun install && bun -p 'require("foo")')   # before: PUBLIC, one foo@1.0.0@@127.0.0.1@@@1
                                                   # after: PRIVATE, foo@1.0.0@@127.0.0.1__<hex>@@@1 per registry

The same collision decides whose postinstall runs when the package is in trustedDependencies, and --frozen-lockfile reinstalls keep linking the wrong bytes.

Folder names

• foo@1.0.0@@@1: default registry (unchanged).
• foo@1.0.0@@nexus.corp__<16 hex>@@@1: non-default registry. The hex is the hash of the registry URL, the same url_hash as in <id>-<url_hash>.npm.
• foo@1.0.0@@other.host__<16 hex>@@@1: a tarball URL that is not <configured registry>/<name>/-/… and not under registry.npmjs.org. That is a lockfile URL from another registry (also one nested under the configured registry), or a registry with its own tarball layout (GitHub Packages, JSR). The hex is the hash of that URL.

The host is shown only when it is a plain name: at most 32 bytes of [A-Za-z0-9.-]. A bracketed IPv6 host, or a host with any other byte, is left out (foo@1.0.0@@__<16 hex>@@@1). The host can now come from a tarball URL in a lockfile or a manifest, so it must not put an arbitrary byte into a path component. The hash carries the identity.

bun.lock writes an npmjs tarball URL as "" and rebuilds it under the configured registry on the next install. A tarball in the configured registry's own layout (<registry>/<name>/-/…, what build_url writes), a tarball under registry.npmjs.org, and an empty URL therefore all name the registry's folder, so the lockfile round trip stays a cache hit. The test asserts this: the --frozen-lockfile reinstall issues no second tarball request. The npmjs test is a prefix test because bun.lock drops every URL under that prefix. The configured registry's test is a layout test because a prefix test also matches a registry nested under it (https://host/nested/ under https://host/).

The one-time move, measured. A cache that the released build filled for http://127.0.0.1:<port>/npm-private/ holds foo@1.0.0@@127.0.0.1@@@1. With that cache:

• released build, fresh project, bun install --offline: installs.
• this branch, fresh project, bun install --offline: error: --offline: "foo" is not in the cache, exit code 1.
• this branch, one online install: 1 tarball request, 0 manifest requests, creates foo@1.0.0@@127.0.0.1__03fc82788f9cc6ac@@@1. The old folder stays on disk until bun pm cache rm.
• this branch, bun install --offline after that: installs.

There is no fallback probe of the old name on purpose. An old @@<host>@@@1 folder does not record which registry on that host filled it, so reading it back is the collision this PR removes.

Alternative a maintainer may prefer. Keep the old name for a registry at an https root with the default port (https://host/) and add the hash only for a port, a path, or http. Distinct registry URLs still get distinct names, and npmmirror, JSR and GitHub Packages users pay nothing. The cost: on a host that serves a root registry and a second registry, a folder that the second registry filled before the upgrade stays reachable from the root registry. This PR hashes every non-default registry so that no old folder is read.

Still open, by design. A lockfile that pins name@version to another package's tarball under registry.npmjs.org names the registry's folder, as every lockfile URL did before this change. (For a non-default configured registry the layout test now sends such a URL to its own folder.) That needs a hostile or hand-edited lockfile. The model in #37756 treats the cache directory as the trust boundary for that case, so this PR does not add a rule for it.

Auto-install. The <cache>/<name>/<version>... index symlink follows the folder name. resolve_from_disk_cache (--prefer-offline in the runtime) passes an empty URL and gets the registry's folder. That path did not resolve a non-default-registry package before this change either (reproduced on the released build). It is a separate bug and this PR does not change it.

Per-call cost, from the diff. cached_npm_package_folder_name_print adds url_is_under_registry against the default registry (one prefix compare, the only added work for a default-registry package) and, when that fails, is_package_tarball_on_registry against the configured registry (four slice compares). URL::parse of the tarball URL runs only for a tarball that names neither registry's folder. folder_name_host scans at most 32 host bytes for a non-default registry. Binary size is not measured (no release builds of the two commits were made). The source change is about 50 lines in one file.

History of this PR. The first revision keyed the folder by the lockfile integrity. That is the shape #37756 rejected, and it needed an integrity parameter on compute_cache_dir_and_subpath that #39016 also adds with a different encoding. The second keyed by the raw tarball URL. Review found the "" round trip described above. A later review found that a prefix test let a registry nested under the configured one fill its folder. The layout test and a fourth test cover that. A self-check then restricted the host part of the name to a plain name, and a review asked for a test of the registry.npmjs.org clause. The branch was rebased onto main on 2026-09-30.

Test runs (debug builds, machine load average above 600).

• The 6 tests of the new block pass at a0bb5d6 and fail on the released build. The IPv6 one needs an IPv6 loopback, so Linux CI skips it (isIPv6()). It ran here.
• bun-install.test.ts at 5f90589: 249 pass. The 13 failures need the public internet (bitbucket, gitlab, https://some.url), as on main.
• At 5f90589: bun-lock.test.ts 40 pass, bun-patch.test.ts 37 pass, config-precedence.test.ts 51 pass, test/cli/run/run-autoinstall.test.ts 12 pass.
• bun-install-registry.test.ts and bun-add.test.ts were last run locally before the rebase, with the same diff minus the layout test.
• VerdaccioRegistry.cacheFolderName(cacheDir, name, version) in test/harness.ts finds the folder by pattern for the three existing tests that asserted @@localhost@@@1.

Two flaky tests met on the way. Both fail the same way on the released build.

• bun-install-offline.test.ts: error: --offline: no cached manifest for "baz" right after an online install of baz. Released build: 4 of 12 runs of the file fail this way. The manifest file is missing, not the extraction folder.
• isolated-install.test.ts, ranged peer dependency resolution is stable across installs from bun.lock: the fresh install binds the peer to no-deps@1.0.1 (+f8a822eca018d0a1) and not to 1.1.0. Released build: 4 of 14 runs.